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REMARKS 



Claims 1-5, and 7-12 were rejected as anticipated by Nazem. 
Claims 6, and 13-15 were rejected as unpatentable over Nazem in 
view of Rune. Applicant requests reconsideration. 

Independent claims 1, 9, and 12 were amended to clearly recite 
that the process steps are executed at a proximal IPA. That is, 
according to claim 3, a proximal web cache. The examination 
recitation of the history of computer caches was elegant, but 
largely unnecessary. 

The basis for allowance is and remains common to claim 1, 9, 
and 12 that include, among others, the unobvious limitation of 
"cross referencing at the proximal IPA in the forwarding table the 
stored destination URL identifier with the destination IPA". 

The invention is directed to forming a proximal web cache that 
functions as both a forwarding table and a routing table, that 
includes both IPA and URL information. The cross-referenced URL-to- 
IPA forwarding table assists the proximal host to locate web 
content data stored in a network of web caches. The benefits of 
associating the URL with IPA enables one to have a self-contained 
content-based forwarding table in a proximal web cache for 
expedited retrieval of web content data. 



/// 
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The present invention is new as a forwarding and routing table 
that associates URLs to distal IPAs for accessing web content data 
from the nearest minimum hop URL data that is stored in a web 
cache. The present invention does not merely route IPAs from a 
routing table for forwarding discrete packets, but rather forwards 
and routes the URL requests to near and far web caches and servers. 
Hence, the present invention is characterized by associating URL to 
distal IPA in a forwarding-routing table in a proximal web cache 
using URL requests that are for retrieving web content data from a 
distal but minimum hop web cache or a distal URL web server 
identified by both the IPA and URL. As such, and using the present 
invention, a web content data requests can be sent, through table 
association, to a minimum hop web cache for fast access, rather 
than to a far remote distal web server. By using the invention, a 
browser directly communicates with a web cache to access web 
content data without a DNS request . 

The examination rejections upon Nezem is without merit. Nazem 
(col. 3, lines 1-5), describes the well-understood prior art by 
which a web browser normally accesses web content data offered by a 
web server using the Domain Name System (DNS) to cross-reference a 
web server name, contained within the URL, to a destination IPA. It 
is kindly but firmly requested that the examination take clear note 
that in Nazem the DNS is ITEM 108, the browser is ITEM 102, the 
distal servers are ITEMS 104 replicated, and there is no WEB cache 
in the Nezem system. 

/// 
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Nezem is directed to the production of on-demand web content 
data. Nezem' s system, comprising ITEMS 112, 114 and 116 generates 
web content data from data sources and user templates. Nezem has 
nothing to do with web caching. There is no reference in Nezem as 
to caching or storing the generated or produced web content data. 
Nezem is IRRELEVANT art. 

The DNS service cross-references the web server names, 
previously extracted from the distal URL, to the web server IPA so 
that communication between the web browser and web server can be 
established and the web content data can be transmitted directly 
between them. The DNS service maintains cross-references from a web 
server name to a list of destination IPAs. 

Nezem' s use of the DNS does not cross-reference distal URLs or 
distal URL prefixes to a destination IPA. The browser extracts the 
web server host name from the URL, communicates the host name to 
DNS, and then the DNS translates host name to a host IPA, and 
communicates the host IPA back to the browser. In web parlance, a 
browser, a web cache, a web server, and a DNS are distinct 
processes. Yet, the examination seems to equate all these function 
with the claimed invention, as if the claimed web cache process is 
ipso facto the entire web complex. 

Nazem (col. 3, lines 10-15) describes the modified operation 
of a DNS name server such that the web server IPA returned to the 
web browser is the same when more than one IPA is associated to a 
web server name. There exist a plurality of methods for selecting a 
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destination IPA from the destination IPA list. Nazem (col. 3, lines 
10-15), describes a desired deterministic method using the 
requesting web browser IPA. The DNS service does not maintain 
cross-references from a URL or prefixed portion of a URL to a list 
of destination IPAs, and therefore does not teach or suggest a 
cross-referenced URL-to-IPA forwarding table. Therefore, neither 
does Nazem. Nazem (col. 2, 52-67, col. 3, 1-15) describes the 
operation of prior art on how a web browser determines how to 
communicate with a web server through DNS requests. Nazem is 
irrelevant to the present invention that uses a forwarding-routing 
table at a proximal IPA web cache that associates URL and IPA for 
intermediate web cache access. 

The examination incorrectly cites Nazem (Col 3 line 1) to 
indicate that there is a cross-referencing, but as discussed, this 
is a DNS request which start by sending the web server name 
extracted from the URL and ends with the DNS service returning an 
IPA to the browser. The proximal IPA forwarding table stores cross- 
references between a distal URL and a destination IPA prior to the 
source sending a source URL identifier. Nazem does just the 
opposite, by sending a URL and receiving an IPA from the DNS. 
Storing the cross-reference between a distal URL or URL prefix and 
a destination IPA is a separate process independent of DNS that is 
not disclosed nor suggested in Nazem. 



/// 
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The present inventions of claim 1, 9, and 12 are characterized 
as creating a f orwarding-routing table in a web cache that 
associates URL and IPAs requests for enabling access to near 
minimum-hop web caches. Nazem does not provide for minimum hop web 
cache access nor does Nazem use a f orwarding-routing table that 
associates URLs and IPAs, but rather Nazem uses conventional DNS 
services for associating the two. Nazem teaches away from the 
present invention. 

When viewing Nezem drawing, it become clear that the functions 
upon which the rejections are based flow from functions of a 
plurality of web processors, including a browser, DNS processor, as 
well as web servers having unique functions. This is a gross 
application of forbidden hindsight reconstruction. It is not 
determinative that a DNS cross-references host names to IPAs, nor 
determinative that cache or memory is well know, but rather the 
invention must be viewed as a whole. In this regard, the 
independent claims have been modified so that each functional 
process steps occurs at a single proximal IPA, so that, the 
examination will cease from incorporating into this sole proximal 
IPA all of the functions that ever existed in connection with web. 

In connection with the independent claims, Nezem specifically 
and particularly teaches a SYSTEM having various components 
including the browser, DNS and web servers interconnected across 
the internet, whereas, the present invention performs modified 
function all within a single process AT THE PROXIMAL IPA. Such a 
cross-referencing web cache AT THE PROXIMAL IPA is not remotely 
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suggested by Nezem. The comments, in the examination, in connection 
storing at a proximal IPA the forwarding table, that Nezem teaches 
IP addresses stored in a name server, equates a DNS server with the 
present invention, but a DNS server does not include a forwarding 
table that translate a URL to a distal IPA, but does include a 
translation from host name to the distal IPA. 

In connection with claim 3 for another example, a DNS has 
never been used to store web content data, yet claim 3 calls out 
that the web content data is received at the proximal IPA as a 
proximal web cache. The examination equates a DNS with forwarding 
table, and with a web cache 

The DNS does not receive, at the proximal IPA, a URL, but 
rather receives host names extracted by a browser and then cross- 
references the host names to a web IPA storing the web content 
data. A DNS is simply not a cross-referencing web cache. 



/// 
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A DNS receives a host name from a browser, not a URL as the 
examination incorrectly suggests. The claimed process receives a 
destination URL for a source. A DNS transmits a destination IPA to 
a browser. The claimed transmits a URL to a destination IPA. A DNS 
does not cache web content data. The claimed invention as in claim 
3 caches web content data. Yet, the basis for the rejections is 
Nezem and the conventional use of DNS. Looking to the examination 
comments on page 3, it is noted that for the 1) storing, 2) 
storing, 3) receiving) 4) cross-referencing, 5) and transmitting 
steps, the repetitive citation of Nezem and the DNS "name server" 
is abundant, yet, a DNS does not perform a single one of these 
functions. How possibly could Nezem be used to reject the present 
sent of claims is beyond comprehension as the examination did not 
in any meaningful regard rebut or counter applicant 1 s last 
argument, excepting of course, the statement that "Applicant's 
arguments have been fully considered but they are not persuasive" . 
The present invention does not use DNS in any regard, nor its well 
understood functions, and as such, Nezem is irrelevant and teaches 
away from the non-DNS use by the present invention, and the 
examination's reliance of Nezem is misplaced. Allowance of the 
claims is requested. Respectfully Submitted 
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